Over the past few years, Ethernet has become the undisputed leading Local Area Network (LAN) technology due to the intrinsic characteristics of the technology, such as being simple to implement and use, cheap to employ, easy to manage, and backward compatible.
With data services now accounting for the bulk of traffic, telecommunication operators and carriers are looking at the possibility of reaping the same benefits by replacing their Synchronous Digital Hierarchy (SDH)/Synchronous Optical Networking (SON ET) infrastructure with an Ethernet-based packet transport infrastructure. However, metro and backbone networks have quite different requirements than enterprise LANs.
Consequently, Ethernet technology requires specific enhancements if it is to fulfill these carrier-grade requirements. Currently, work is being carried out at the Institute of Electrical and Electronics Engineers (IEEE) on the Provider Backbone Bridge Traffic Engineering (PBB-TE) concept, to implement Ethernet technology for carrier use. There is an amendment to the IEEEE P802.1Q standard being discussed (IEEE P802.1Q-2006/D0.1, Draft IEEE Standard for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks), which is intended to provide a true carrier-grade packet transport solution based on Ethernet.
PBB-TE (i.e. IEEE 802.1Qay/D0.0, Draft Standard for Local and Metropolitan Area Networks-Virtual Bridged Local Area Networks: Provider Backbone Bridges—Traffic Engineering, May 2007) proposes a simple, connection-oriented solution. This implementation maintains the inherent advantages of Ethernet, while addressing the deficiencies of Ethernet as a carrier-class packet transport protocol. It builds upon the concepts brought forth in the amendments to IEEE 802.1Q and, in particular, the network separation of PBB (i.e., IEEE 802.1Qah/D3.8, Draft Standard for Local Metropolitan Area Networks—Virtual Bridged Local Area Networks: Provider Backbone Bridges, October 2007) to provide a scalable solution.
In contrast to Provider Backbone Bridging (PBB), spanning tree protocols and broadcasting/flooding are not used in PRB-TE. Filtering databases are populated using a network management system or an enhanced control plane, allowing Ethernet Switched Paths (ESPs) to be engineered and provisioned across the network. This allows control of traffic flow through the Ethernet-based packet transport network which ensures an optimal allocation of resources. Each ESP represents a unidirectional path. A pair of ESPs that form a bidirectional path across the network defines a PBB-TE trunk or tunnel.
One of the key points addressed in PBB-TE is how to provide end-to-end linear protection for PBB-TE trunks, where a dedicated protection PBB-TE trunk is established for a particular trunk, and the traffic is automatically switched from the working (primary) PBB-TE trunk to the protection (backup) PBB-TE trunk when a failure occurs on the primary trunk.
FIG. 1 is a simplified block diagram illustrating essential elements of an end-to-end linear protection scheme 10 and its arrangement in existing networks for a protection entity 12. The scheme employs normal traffic over an ESP 14 as a working entity and an ESP 16 as a protection entity between a West component 18 and an East component 20. The West component includes a protection switching process 22 and the East component includes a protection switching process 24. At the sending ends, traffic may be arranged in two ways. First, in a 1+1 arrangement, traffic is sent on both the working and protection paths simultaneously (bridged). Second, in a 1:1 or 1 for 1 arrangement, traffic is sent on only one of the paths at any point in time (switched). In both protection arrangements the receiving end selects traffic from the working or protection entities based on information from Operations, Administration and Management (OAM) processes or network operators. In the 1 for 1 case, the sending “protection bridge” and receiving “selector” must be coordinated.
International Telecommunication Union-Telecommunication (ITU-T) defines the term “bridge” for the switch that selects either or both of the transmit paths at the sending end of a protection domain. It should be understood that this is not the same definition as the term “bridge” utilized in the IEEE 802 standard. As defined in the present invention, the ITU-T linear protection bridge refers to a “protection bridge”.
In unidirectional linear protection schemes, the selectors at each end of the protection domain operate asynchronously. Specifically, a traffic path selection action at one end does not result in a traffic selection action at the other end on traffic in the reverse direction. Consequently, traffic in one direction may use a different path from the traffic in the other direction.
However, bidirectional linear protection schemes operate synchronously in the sense that a traffic selection action at one end also triggers a corresponding selection action at the other end on traffic in the reverse direction. Thus, traffic in both directions share the same path (i.e., either working or protection).
Protection switching may be triggered by OAM information arising from periodic monitoring of the working and protection paths or from physical layer monitoring, such as loss of signal or frame errors detected through frame check sequence.
Linear protection schemes are usually configurable to be “revertive” or “non-revertive”, where reception and transmission traffic, where applicable reverts, to the working path automatically once OAM indicates the fault or defect has cleared.
Most linear protection schemes now aim to switch completely (both ends where appropriate) in less than 50 ms from the occurrence of the fault, not just from the OAM defect indication. Consequently, the periodicity of OAM continuity check messages has to be nearly an order faster to detect the fault and transport the synchronization information end to end.
Most schemes also incorporate hold-off and wait to restore timers. Hold-off times ensure the fault is not just a transient event, arising from some lower level protection switching for instance, while restore times ensures the performance of the working path is fully restored before switching back to it. Obviously, the overall recovery time is greater.
Thus, a scalable end-to-end sub-50 ms resiliency mechanism that offers bidirectional end-to-end linear protection capabilities for point-to-point PBB-TE tunnels or trunks in a PBB-TE domain is needed.
Today, different proprietary and standard based resiliency mechanisms are used within Ethernet networks, such as Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), Resilient Packet Ring (RPR), and Link Aggregation (LAG). However, these mechanisms are limited to link failures and are not designed to easily scale in large networks. Furthermore, they do not support sub-50 ms protection switching in either a ring or linear environment. In addition, since spanning tree protocols are not used in PBB-TE, this also excludes their use from the onset as a potential solution for offering PBB-TE trunk resiliency.
In SDH/SONET networks, the Automatic Protection Switching (APS) function and protocol provides end-to-end circuit protection. This APS function and protocol can support 50 ms switchover, unidirectional and bi-directional switchover, revertive and non-revertive switchover, manual, and/or automatic switchover. The APS function may also support linear, ring, and mesh topologies. APS enables the switchover of circuits in case of circuit failure and is utilized in most synchronous networks.
ITU-T, through the G.8031/Y.1342 Recommendation, defines the use of the APS function and protocol for point-to-point VLAN-based subnetwork connection in Ethernet transport networks. The APS protocol is used to co-ordinate the two ends of a protection domain. APS messages are only sent on the protection path. Direct application of the G.8031 mechanisms on in a PBB-TE domain introduces additional complexity as the advent of the APS Protocol Data Unit (PDU) for signaling purposes contains substantial redundant information leading to a non-cost efficient solution.
For example, the G.8031 Recommendation states it is desirable for Continuity Check Messages (CCMs) to be sent with an interval of 3.3 ms and for the first three APS messages (resulting from a protection switch event at the originating end) to also be sent with a similar interval of 3.3 ms and then again with an interval of 5 seconds. This permits the loss of up to two APS messages due to errors or other phenomena while still achieving a 50 ms protection switch time.